Gearing up for CentOS 6.0!

We are gearing up for CentOS 6.0!

The painting was on the wall: Sooner or later CentOS 6.0 will hit us and we better be ready for it. There is no time to rest on past laurels and achivements - is it?

We already had some ideas as of what to expect. After all, we could take a look at Fedora Core 12 and make some educated guesses as of what version of PHP or which version of Apache we could roughly expect to be present in CentOS6.

So we had to prepare for PHP-5.3.1, which sort of was bad news for us:

The obstacles of PHP-5.3:

The Sausalito interface itself was developed with PHP-3.9 in mind. Eventually it became PHP-4.1 ready and even managed to get as far as PHP-4.3.9 during BlueQuartz days.

When we forked BlueOnyx we already had to go through the troubles of making it PHP-5.1 ready, which was a very major effort and undertaking. The differences between PHP-4 and PHP-5 are legion and many things that did work before now no longer worked.

With BlueOnyx on CentOS6 and with PHP-5.3.1 we're facing an even bigger challenge than ever before:

POSIX vs. PCRE:

As of PHP 5.3.0, the POSIX Regex extension is deprecated:

This means that we have to go through the entire GUI and have to replace all the old ereg_replace(), ereg(), eregi_replace(), eregi(), split() and spliti() functions with their newer PCRE compliant counterparts.

That alone can make a grown man cry. Especially when some changes - such as deprecating the trusty old split() - make no bloody sense at all. It's just hillariously stupid and you can bet that much cursing will ensue during the long hours that we clean up our code. The rough estimate is that it'll take 2-3 weeks alone just to replace all old functions with new ones.

Assigning return values by reference:

Throughout the GUI we have pages that use code like this:

$helper =& new ServerScriptHelper();

Which now generates the error message "Error: [] Assigning the return value of new by reference is deprecated". The fix is fairly simple, though:

$helper = new ServerScriptHelper();

But of course it also adds to our work load as we have to find and fix each of those references.

Globals:

This has been comming for a long time and for a good reason. And of course we're not yet ready for it. But this time we can't dodge that bullet. The implications are many and it will be a major struggle.

Register Globals:

Our php.ini for AdmServ of course uses "Register_Globals = On", because we have a lot of legacy code that requires it. While we could still leave it on for now under PHP-5.3, it will throw "deprecated" warnings six days 'til Sunday. And eventually when PHP-6 hits, it'll bite us again and probably also much harder.

But it also means that we have to go the entire codebase to change our code form the old globals to the new ones: 

While that is already a major undertaking - it gets worse than that:

Sausalito-palette:

This Sausalito package has always been somewhat misnamed. Basically it's the heart and soul of the UI, or its very core. It defines functions and classes, which the individual GUI pages use. This starts with authentication when you login to the GUI. It also takes care that you only see the pages that you have privileges to see. It also defines how certain re-useable code blocks like Buttons, MultiChoice selectors, ScrollLists or certain forms look and behave.

That then also ties in closely to the theming engine, which allows the GUI to be "skinned" with various skins that alter the appearance.

When "register_globals" is set to "Off", then the very first thing that happens is that you cannot login to the GUI anymore, as the username and password submitted to CCE are now empty. You guessed it right: They used the old $HTTP_POST_VARS instead of the new $_POST variable.

Even once that's fixed, Cookies are used to allow you to remain logged in. We then have the next problem there: $HTTP_COOKIE_VARS needs to be replaced with $_COOKIE to make sure that this also works as expected.

While many of these elementary functions are used in Sausalito-Palette, there is also a lot of usage of $HTTP_POST_VARS and $HTTP_GET_VARS in the rest of the GUI code, like the individual modules.

So just getting authentication to work again with "register_globals = off" will be a challenge that exceeds all the achievements that we pulled off so far. Especially as the whole security model of the GUI has to be re-evaluated and in the light of the fact that we have to declare many globals at the very beginning to make sure that their contends are useable from all subordinate code segments. That'll be fun!

In closing - for now:

As you can see, we have much work ahead in the following months and weeks until CentOS 6.0 is released sometime this fall. But it's no time for idle hands and there is much work to do.

The result will hopefully be worth it, but that will be up to you - the BlueOnyx users - to decide.